Release 10.1A: OpenEdge Development:
AppBuilder

How the CascadeOnBrowse property works

When this property is set (the default), navigation changes propagate downstream to every object in the DATA links chain. Clearing this check box causes navigation changes to propagate downstream only until more than one record is returned.

Using the situation in Figure 4–4 as an example, selecting a different customer causes that customer’s orders to be found and displayed. That in turn causes the order lines for the first order to be found and displayed and finally the items and inventory records for the first order line.

Keeping the entire data stream constantly synchronized in this way can represent a significant overhead expense. It can slow your application unacceptably, especially if the user is looking for a particular record rather than examining each one.

To reduce the problem, you can choose to clear the CascadeOnBrowse property.

In Figure 4–4, if the user selects a different Customer record, the Order object will be directed to fetch the orders associated with this new customer. If there is only one order record, the OrderLine object will in turn be directed to fetch the records associated with that order. If there is only one OrderLine record, the Item and Inventory objects will fetch the records associated with that order line.

But if, for example, the OrderLine object returns more than one record, then synchronization stops there. The Item and Inventory objects are not instructed to resynchronize themselves. The Item and Inventory record data for the previous Customer are simply discarded from the temp-table because they are not relevant to the current Customer.

To achieve additional levels of detail when CascadeOnBrowse is not set, the user must select one of the records that stopped the resync operation. This will cause the SmartBusinessObject to start resyncing again, from that level downward. Of course, if the next level below that point also returns multiple records, then resync would again stop and have to be restarted again from that new level.

So, if you believe the users of your application would prefer completeness at some cost in performance, leave CascadeOnBrowse set. If you believe users would prefer higher performance at the cost of having to explicitly restart resynchronization when needed, clear the property.

Caution: If you clear this property, it might not be immediately obvious to the user why resynchronization propagates fully in some cases but not others. To limit the number of support calls you receive, you might wish to explain this behavior in your documentation and training.